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APPEAL BRIEF 

L REAL PARTY IN INTEREST 
This application is assigned to International Business Machines Corporation, of Armonk, 
New York. 

H. RELATED APPEALS AND INTERFERENCES 
There are no related appeals or interferences. 

m. STATUS OF CLAIMS 
Claims 1-26 are pending in the Application. All pending claims stand rejected, and are 
now on appeal. 

IV. STATUS OF AMENDMENTS 
No amendments have been filed prior to or subsequent to final rejection (Paper No. 11). 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 
Applicant's invention is generally directed to an apparatus, program product and method 
that locally track protocol progress information within each member of a group of a clustered 
computer system, for the purpose of identifying at least one problematic member of the group. 
By locally tracking such information, any member of the group may be directed to provide such 
information on demand in response to a query directed to such member. As a consequence, if 
there are AT members of a group, and one is problematic, the probability of successfully obtaining 
the protocol progress information via a query directed to an arbitrary group member is at worst 
(N-l)/N (assuming a problematic member is incapable of responding to a query). Typically, in 
such a situation, at most two requests would be needed to obtain the necessary information. 

A clustered computer system is a computer system where multiple computers, or nodes, 
are networked together to present a single system image (Application, p. 1, lines 10-14). Clusters 
perform tasks through the performance of jobs running on each node, which maybe logically 
organized together into a "group" to perform collective tasks, where each affiliated job is referred 
to as a "member" of the group (Application, p. 2, lines 1-5). Joint operations performed by 
members of a group are referred to as "protocols" and in some clustered systems these protocols 
are implemented as 4 *peer protocols", where "all members receive a message and each member is 
required to locally determine how to process the protocol and return an acknowledgment 
indicating whether the message was successfully processed by that member" (Application, p. 2, 
lines 13-16). 

Applicants invention addresses the problem that arises in clustered computer systems 
whereby the failure of a member of a group to respond quickly (or at all) to a protocol request 
will typically slow down the rest of the members, often because each member is required to wait 
for acknowledgments from all other members before proceeding on to a next protocol 
(Application, p. 2, lines 19-30). Traditionally, when one member is stuck or slow, all members 
appear to be stuck or slow as well, and as a result, it becomes difficult to isolate the problem to a 
particular member. 
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Embodiments of the invention address this problem by requiring each member to locally 
track protocol progress information, and then configuring each member to respond to a query by 
providing its locally tracked protocol progress information (Application, p. 4, lines 1-12). 

In some embodiments, each member participating in a protocol is required to send an 
ACK message to each other member in the group when the member has completed processing of 
the protocol. In this regard, protocol progress information may be locally tracked by tracking, 
within each member, a current ACK round for such member, as well as the last ACK round 
received from each other member (Application, p. 10, lines 3-17). By doing so, identification of 
a slow or stuck member is often trivial from a review of the protocol progress information, as a 
slow or stuck member will have a last ACK round received value that lags that of the other 
members (Application, p. 10, lines 18-25). 

An additional feature supported by embodiments of the invention is the ability to monitor, 
in a member of a cluster group, for receipt of a query message while that member is waiting on a 
resource, and providing protocol status information in response to receipt of the query message 
(Application, p. 4, lines 18-22). This feature maybe implemented, for example, by placing 
protocol messages on a message queue in a member, and continuing to monitor for query 
messages while a protocol is being processed and waiting on a resource (Application, p. 12, line 
14-p. 13, line 12, Fig. 6). The protocol being waited upon may be a peer protocol, or a local 
protocol, e.g., a protocol waiting on a lock or a creation of a new job (Application, p. 1 1, lines 3- 
9). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 
Claims 1-26 stand rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 
No. 6,392,993 to Hamilton et al. (hereinafter Hamilton). 
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VH. ARGUMENT 
A. Claims 1-26 are not anticipated by Hamilton 

Applicants respectfully submit that the Examiner's rejections of claims 1-26 are not 
supported on the record, and should be reversed. Anticipation of a claim under 35 U.S.C. §102 
requires that "each and every element as set forth in the claim is found, either expressly or 
inherently described, in a single prior art reference." Verdegaal Bros.* Inc. v . Union Oil Co. 2 
USPQ2d 1051, 1053 (Fed. Cir. 1987), quoted in In re Robertson, 49 USPQ2d 1949, 1950 (Fed. 
Cir. 1999). Absent express description, anticipation under inherency requires extrinsic evidence 
that makes it clear that "the missing descriptive matter is necessarily present in the thing 
described in the reference, and that it would be so recognized by persons of ordinary skill" 
Continental Can Co. v. Monsanto Co.. 20 USPQ2d 1746, 1749 (Fed. Cir. 1991), quoted in Inre 
Robertson at 195 1 . "Inherency, however, may not be established by probabilities or possibilities. 
The mere fact that a certain thing may result from a given set of circumstances is not sufficient." 
Continental Can at 1749, quoted in In re Robertson at 1951. 

Applicant respectfully submits that Hamilton does not disclose the various features 
recited in claims 1-26, and as such, the rejections thereof should be reversed. Applicant will 
hereinafter address the various claims that are the subject of the Examiner's rejection in order, 
starting with the independent claims, and then addressing additional dependent claims reciting 
additional subject matter that is distinguishable from Hamilton. 

Independent Claim 1 

Turning first to the rejection of independent claim 1, this claim generally recites a method 
of determining a status of a peer protocol initiated on a plurality of members of a group in a 
clustered computer system. The method includes locally tracking protocol progress information 
within each member of the group, and responding to a query directed to a selected member of the 
group by providing the protocol progress information locally tracked by the selected member. 

Hamilton, on the other hand, lacks a number of features recited in claim 1, and therefore 
falls short of anticipating the claim. In particular, claim 1 recites a method of determining the 
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status of a "peer protocol" initiated on a plurality of members of a group in a "clustered computer 
system." Hamilton, on the other hand is completely silent with respect to clustering or to peer 
protocols. Indeed, neither concept is mentioned in the entirety of Hamilton. Furthermore, given 
that these limitations in the preamble serve to define terms used elsewhere in the claim, these 
limitations are properly subject to patentable weight. 

As noted above, a peer protocol in a clustered computer system is a protocol where "all 
members receive a message and each member is required to locally determine how to process the 
protocol and return an acknowledgment indicating whether the message was successfully 
processed by that member" (Application, p. 2, lines 13-16). Hamilton* on the other hand, is 
directed merely to a multicasting protocol, where a transmitting system sends multi-packet 
messages to a plurality of recipients, with the option of requesting acknowledgments from the 
recipients (referred to as a '^positive reliability mode".) The transmitting system tracks 
acknowledgments received from recipients, and retransmits when acknowledgments are not 
received from all recipients (abstract). Of note, however, the recipients do no tracking of status 
other than whether all packets of a message are received by that recipient (col. 12, lines 50-55), ■ 
which may be used to force a NAK to be returned to the transmitting system when some of the 
packets of a message are never received. There is no disclosure in Hamilton of any functionality 
analogous to a "peer protocol" as recited in claim 1 . 

The Examiner apparently argues in the Final Office Action of July 23, 2004, that 
Hamilton discloses a peer protocol by virtue of the disclosure of a UDP protocol, and 
furthermore, that the clients and servers in Hamilton correspond to a "group" as claimed. The 
Examiner's argument, however, disregards the additional characterization in claim 1 of the peer 
protocol being initiated on a plurality of members of a group **in a clustered computer system." 
Clustering is a well understood concept in the art, and is not merely a collection of networked 
computers. As noted above, clustering implies multiple computers participating in protocols and 
presenting a single system image. A simple UDP protocol as relied upon by the Examiner, used 
to communicate between clients and servers, does not correspond to a peer protocol in a clustered 
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computer system as defined in claim 1 . Therefore, Applicants submit that Hamilton fails to 
anticipate this feature of claim 1 , 

In addition, claim 1 recites the concept of locally tracking the "protocol progress 
information 1 ' within "each member of the group." Put another way, every member of the recited 
group is responsible for locally tracking the progress of the peer protocol. As noted above, 
however, Hamilton discloses only a multicasting messaging protocol that, in one embodiment, 
utilizes a positive reliability mode whereby recipients of a multicast message send 
acknowledgments back to a sending system. Columns 3 and 4 of the reference, which have been 
cited by the Examiner, merely disclose that a sending system is capable of tracking 
acknowledgments received from the recipient systems to which a packet has been sent. This 
disclosure, however, is deficient in several regards. 

First, tracking the receipt of acknowledgments to a packet falls short of "locally tracking 
protocol progress information." As described, for example, at page 2 of the application, a 
"protocol" in the context of a clustered computer system refers to the performance of operations 
to be performed by the members of a group in a cluster. Lines 13-20, in particular, describe how 
peer-type protocols are handled by multiple members using ordered message-based 
communications. Members are prohibited from proceeding on with other work until 
acknowledgments from all members for a particular requested protocol have been received. The 
simple transmission of a multicast packet is not analogous to a "protocol," and as such, tracking 
acknowledgments to a multicasting packet is not analogous to tracking the progress of a protocol. 

Second, claim 1 recites that the local tracking of protocol progress information is 
performed by each member of the group. The passages cited by the Examiner in Hamilton, 
however, merely disclose a single system (the sending system) that arguably tracks the receipt of 
acknowledgments from recipient systems. There is nothing in the cited passages that discloses or 
even suggests that the recipient systems locally track progress information related to the 
acknowledgments sent by other recipient systems. Put another way, Hamilton does not disclose 
multiple systems, much less each system, tracking acknowledgments. 
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The Examiner apparently argues in the Final Office Action of July 23, 2004, that the fact 
that each recipient in Hamilton tracks the reception of packets in a message, and sends a NAK 
when all packets are not received, corresponds to locally tracking "protocol progress 
information". However, as noted above, "protocol progress information" relates to the progress 
of a peer protocol, not simply the receipt of data. Indeed, given Hamilton merely tracks packets 
in a multi-packet message, Hamilton at most tracks receipt of a message in each recipient This 
falls far short, however, of tracking the status of a protocol, much less a protocol that requires 
participation by multiple members of a group in a clustered computer system. Applicants 
therefore submit that Hamilton fails to anticipate this feature of claim 1. 

Claim 1 additionally recites the concept of responding to a query directed to a selected 
member of a group by providing the protocol progress information locally tracked by that 
selected member. Here, the Examiner again cites column 4 of Hamilton, and in particular, lines 
9-17. The cited passage, however, is completely silent with respect to a query that is responded 
to by providing protocol progress information . The cited passage instead discusses reply 
messages, which are sent whenever a particular request that has been sent out demands a 
response, which is above and beyond an acknowledgment. However, the replies described in this 
passage are not analogous to queries within the context of claim 1. One aspect of the invention 
recited in claim 1 is that a query can be sent to a member of a cluster group to request that the 
progress information being tracked by that member be output as a response to the query. There is 
nothing in Hamilton, on the other hand, that discloses or suggests that the acknowledgments that 
are tracked in a sending system of Hamilton are ever provided in response to a particular query 
directed to the sending system. 

Indeed, the Examiner fails to address this feature in the Examiner's response to 
Applicants' arguments in the Final Office Action of July 23, 2004. However, taking the 
Examiner's other position in the Examiner's response to Applicants' arguments that protocol 
progress information is met by each client keeping a list of received packets, and sending NAK's 
when a packet is not received after expiration of a timer, the Examiner would be required to 
show that Hamilton teaches providing the protocol progress information maintained on a client 
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(e.g., the list of received packets) in response to a query message directed to that client. 
Hamilton, however, lacks any such functionality, and thus fails to disclose this feature of claim 1. 
Moreover, even if the Examiner takes the position that the transmission of a NAK corresponds to 
providing protocol progress information, it is important to note that this transmission occurs in 
response to expiration of a timer, rather than in response to a query directed to the client, as 
would be required to anticipate claim 1. 

Accordingly, Applicant respectfully submits that Hamilton fails to disclose each and 
every feature recited in claim I . Claim 1 is thus novel over Hamilton. 

Applicant also respectfully submits that claim 1 is non-obvious over Hamilton, as there is 
no suggestion in Hamilton or elsewhere in the prior art to modify the multicasting protocol of 
Hamilton to be used in a clustered computer environment, nor to provide the ability to both 
locally track the progress of a peer protocol and respond to a query directed to a particular 
member that results in the output of the tracked information. Accordingly, Applicant also 
respectfully submits that claim 1 is non-obvious over Hamilton and the other prior art of record. 
Reversal of the Examiner's rejection of claim 1, as well as allowance of the claim, and of claims 
2-13 which depend therefrom, are therefore respectfully requested. 

Independent Claims 14. 22 and 23 

Next, with respect to independent claims 14, 22, and 23, as with claim 1, each of these 
claims recites the concept of tracking the status of a peer protocol initiated on a plurality of 
members of a group in clustered computer system. Furthermore, each of these claims likewise 
recites the provision of tracked protocol progress information in response to a query directed to a 
member of the group. As discussed above in connection with claim 1, Hamilton neither 
discloses nor suggests either the tracking of the progress of a peer protocol initiated on a plurality 
of members of a group in a clustered computer system, or the provision of tracked protocol 
progress information in response to a specific query directed to one of the members. 

Furthermore, with respect to claims 14 and 23, the fact that the protocol progress 
information is being tracked for a peer protocol initiated on a plurality of members of a group in 
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a clustered computer system is recited in the body of the claims, so the Examiner cannot discount 
these features solely due to their presence in the preamble of a claim. In addition, with respect to 
claim 22, this claim recites "a clustered computer system", which is simply not disclosed in 
Hamilton. 

Accordingly, Applicant respectfully submits that independent claims 14, 22, and 23, as 
well as claims 15-21 and 24 which depend therefrom, are novel and non-obvious over Hamilton 
and the other prior art of record. Reversal of the Examiner's rejections, and allowance of these 
claims are therefore respectfully requested. 

Independent Claim 25 

Next, with respect to independent claim 25, this claim recites an apparatus that includes a 
memory, and a program that monitors for a receipt of a query message by a member of a group in 
a clustered computer system while a current protocol for the member is waiting on a resource. 
The recited program also outputs protocol status information in response to receipt of the query 
message. 

In rejecting claim 25, the Examiner relies on columns 3 and 4 of Hamilton. Hamilton, 
however, is deficient in a number of respects. First, as discussed above with respect to the 
preceding claims, Hamilton is not directed to a clustered computer system, and thus fails to 
disclose or suggest the concept of protocols, groups, members, or clustering. In addition, the 
cited passages are entirely silent with respect to the concept of waiting on a resource, much less 
monitoring for receipt of a query message while a current protocol is waiting on the resource. 

Hamilton also fails to disclose the outputting of protocol status information in response to 
receipt of a query. From Applicant's reading of the reference, it appears that, while 
acknowledgments to particular packets are tracked by a sending system, and receipt of packets in 
a multi-packet message are tracked by recipients, there is no mechanism by which such tracking 
information is ever output by a sending or receiving system. Applicants also could find no 
disclosure in Hamilton corresponding to a query message that triggers the output of any such 
information. Put another way, it appears the Hamilton tracking is a purely internal mechanism. 
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In contrast, embodiments consistent with the invention recited in claim 25 may be used, 
for example, to assist in identifying slow or stuck members in a cluster that may be degrading the 
overall performance of other members. As discussed, for example, at page 13, lines 18-29, 
embodiments consistent with the invention recited in claim 25 are able to respond to status 
queries even when waiting on resources. Furthermore, through the local tracking of protocol 
progress, the identification of a slow or stuck member does not require accessing that stuck or 
slow member, and as a result, may assist in diagnosing problems in a much quicker and more 
efficient manner than would otherwise be required. 

Hamilton appreciates none of these features, and as such, fails to anticipate claim 25. 
Furthermore, no evidence of a motivation to modify Hamilton to incorporate any such 
functionality has been presented, and Hamilton therefore fails to render claim 25 obvious. 
Reversal of the Examiner's rejection of claim 25, and allowance of this claim, and of claim 26 
which depends therefrom, are therefore respectfully requested. 

Dependent Claims 2 and 15 

Dependent claims 2 and 15 are not argued separately. 

Dependent Claims 3. 4 and 16 

Claims 3, 4 and 16 depend from claims 1 and 14, and are thus patentable based upon their 
dependency upon these independent claims. However, each of these claims additionally recites 
the concept of acknowledgment rounds that track the last acknowledgments received from other 
members of a group. Hamilton is entirely silent with respect to the concept of acknowledgment 
rounds, as the packets sent in Hamilton are not ordered or associated with peer protocols within 
the context of the invention. 

Furthermore, the information being tracked includes last ACK round received from other 
members of a group, as well as a current ACK round for the local member. As noted above, 
Hamilton discloses at most local tracking of packet status in individual senders and recipients. 
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Neither the sender, nor any recipient, tracks all of such information, and accordingly, Hamilton 
fails to anticipate this additional feature of claims 3, 4 and 16. 

Reversal of the Examiner's rejections of claims 3, 4 and 16, and allowance of these 
claims, are therefore respectfully requested 

Dependent Claim 5 

Dependent claim 5 is not argued separately. 

Dependent Claims 6 and 17 

Claims 6 and 17 depend from claims 1 and 14, and are thus patentable based upon their 
dependency upon these independent claims. In addition, claims 6 and 17, similar to claim 25, 
recite the concept of waiting on a resource required by a protocol, and monitoring for receipt of 
the query while waiting on the resource. As noted above in connection with claim 25, Hamilton 
is entirely silent with respect to monitoring for receipt of a query for progress information while 
waiting for a resource required by a protocol. The fact that Hamilton arguably discloses tracking 
ACK messages falls far short of disclosing monitoring for receipt of a query while waiting on a 
resource. 

Accordingly, claims 6 and 17 are additionally distinguishable over Hamilton based upon 
these additional features. Reversal of the Examiner's rejections of claims 6 and 17, and 
allowance of these claims, are therefore respectfully requested. 

Dependent Claims 7 and 18 

Claims 7 and 18 depend from claims 1 and 14, and are thus patentable based upon their 
dependency upon these independent claims, hi addition, these claims recite that the protocol 
being waited upon is a peer protocol, which as noted above, is described at page 2 of the 
application as requiring that all members receive a message, and each member locally determine 
how to process the message and return an acknowledgment indicating whether the message was 
successfully processed by that member. The protocol recited in these claims relies on tracking 
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progress locally in each member, Hamilton, in contrast, discloses only the sending of 
acknowledgments by receiving systems to a single sending system, and thus falls far short of 
disclosing waiting on a peer protocol, as noted above. 

Accordingly, claims 7 and 1 8 are additionally distinguishable over Hamilton based upon 
these additional features. Reversal of the Examiner's rejections of claims 7 and 18, and 
allowance of these claims, are therefore respectfully requested. 

Dependent Claims 8 and 19 

Claims 8 and 19 depend from claims 1 and 14, and are thus patentable based upon their 
dependency upon these independent claims. In addition, these claims recite that the protocol 
being waited upon is a local protocol, and that the resource being waited on is a local resource, 
Hamilton is entirely silent with respect to the concept of a local protocol or a local resource. The 
cited passage at col. 28 merely discloses the tracking of ACK messages, and the Examiner 
provides no indication of what the Examiner considers to correspond to a local protocol or 
resource that is waited upon. 

Accordingly, the Examiner has failed to establish anticipation of claims 8 and 19. 
Reversal of the Examiner's rejections of claims 8 and 19, and allowance of these claims, are 
therefore respectfully requested. 

Dependent Claim 9 

Claim 9 depends from claim 1, and is thus patentable based upon its dependency upon 
this independent claim. In addition, the claim recites that the local resource is selected from the 
group consisting of a lock and creation of a new job. The cited passage in Hamilton, at column 
27, lines 20-21, is entirely silent with respect to either a lock or a new job, and as such, the 
Examiner has failed to meet the burden required to establish anticipation of this claim. Reversal 
of the Examiner's rejection of claim 9, and allowance of this claim, are therefore respectfully 
requested. 
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Dependent Claim 10 

Claim 10 depends from claim 1, and is thus patentable based upon its dependency upon 
this independent claim. In addition, the claim recites the monitoring of a local message queue for 
receipt of a query message. As discussed above in connection with claim 25, Hamilton is 
entirely silent with respect to monitoring for receipt of a query. In addition, Applicant can find 
no disclosure in Hamilton, and in particular, in the cited passage at column 28, lines 33-49, 
purporting to disclose the concept of a message queue or of the monitoring of receipt of a query. 

Applicants therefore respectfully submit that the Examiner has failed to meet the burden 
required to establish anticipation of this claim. Reversal of the Examiner's rejection of claim 10, 
and allowance of this claim, are therefore respectfully requested. 



Dependent Claims 1L 12 and 20 

Claims 1 1, 12 and 20 are not argued separately. 



Dependent Claims 13 and 21 

Claims 13 and 21 depend from claims 1 and 14, and are thus patentable based upon their 
dependency upon these independent claims. These claims additionally recite that each member 
of the group locally tracks protocol progress information associated with each other member in 
the group. As such, every member in a group is required to track protocol progress information 
for at least one other member of the group. 

In rejecting claims 13 and 21, the Examiner relies on cols. 27 and 28 of Hamilton; 
however, the cited passages merely disclose the ability of a sending or transmitting system to 
track acknowledgments received from recipients. In addition, Hamilton discloses, as noted 
above, the ability for recipients to track non-receipt of packets in a multi-packet message; 
however, this tracking performed by a particular recipient is only for packets directed to that 
recipient. No recipient is able to track packets directed to other recipients. Therefore, even 
assuming arguendo that the recipients in Hamilton track protocol progress information, these 
recipients do not do so for other entities in the network. 
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Claims 13 and 21 require that each member of a group track protocol progress 
information for each other member of the group. Thus, even if the Examiner argues that the 
tracking being performed by a sending or transmitting system corresponds to tracking protocol 
progress information for other members of a group, the recipients are not capable of tracking any 
progress information for any other member, and as such, Hamilton would still fall short of 
disclosing this claimed feature. Accordingly, the Examiner has failed to establish anticipation of 
claims 13 and 21. Reversal of the Examiner's rejections of claims 13 and 21, and allowance of 
these claims, are therefore respectfully requested. 

Dependent Claims 24 and 26 

Dependent claims 24 and 26 are not argued separately. 



DC. CONCLUSION 

In conclusion, Applicant respectfully requests that the Board reverse the Examiner's 
rejections of claims 1-26, and that the Application be passed to issue. If there are any questions 
regarding the foregoing, please contact the undersigned at 513/241-2324. Moreover, if any other 
charges or credits are necessary to complete this communication, please apply them to Deposit 
Account 23-3000. 

Respectfully submitted, 



Date: /^/^ /o</ 

2700 Carew Tower 
441 Vine Street 
Cincinnati, Ohio 45202 
(513) 241-2324 



WOOD, HERRON & EVANS, L.L.P. 
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Claims Appendix : Claims on Appeal 09/732, 189 

X. CLAIMS APPENDIX: CLAIMS ON APPEAL fS/N 09/732,189) 

1. (Original) A method of determining a status of a peer protocol initiated on a plurality 
of members of a group in a clustered computer system, the method comprising: 

(a) locally tracking protocol progress information within each member of the 
group; and 

(b) responding to a query directed to a selected member of the group by providing 
the protocol progress information locally tracked by the selected member. 

2. (Original) The method of claim 1, wherein locally tracking protocol progress 
information includes tracking, within a first member of the group, acknowledgment (ACK) 
messages directed to the first member by each other member of the group. 

3. (Original) The method of claim 1, wherein locally tracking protocol progress 
information includes: 

(a) tracking, within a first member of the group, a current acknowledgment 
(ACK) round for the first member, the current ACK round associated with a current peer 
protocol being processed by the first member; and 

(b) tracking, within the first member, a last ACK round received parameter 
associated with each other member of the group, the last ACK round received parameter 
for each other member identifying a peer protocol associated with a last received ACK 
message from such other member. 

4. (Original) The method of claim 3, wherein locally tracking protocol progress 
information further includes updating the current ACK round for the first member in response to 
receipt of ACK messages for the current peer protocol from all other members of the group. 
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Claims Appendix : Claims on Appeal 09/732,189 

5. (Original) The method of claim 1 1 wherein locally tracking protocol progress 
information includes updating the protocol progress information for a first member of the group 
in response to receipt of an acknowledgment (ACK) message directed to the first member. 

6. (Original) The method of claim 1, further comprising: 

(a) waiting on a resource required by a protocol being processed on the selected 
member; and 

(b) monitoring for receipt of the query by the selected member while waiting on 
the resource. 

7. (Original) The method of claim 6, wherein the protocol is a peer protocol, and 
wherein waiting on the resource includes waiting for receipt of an acknowledgment (ACK) 
message directed to the selected member. 

8. (Original) The method of claim 6, wherein the protocol is a local protocol, and 
wherein waiting on the resource includes waiting on a local resource requested by the selected 
member. 

9. (Original) The method of claim 8, wherein the local resource is selected from the 
group consisting of a lock and a creation of a new job. 

10. (Original) The method of claim 6, wherein waiting on the resource includes waiting 
for receipt of a message by a local message queue for the selected member, and wherein 
monitoring for receipt of the query includes monitoring the local message queue for receipt of a 
query message. 

1 1 . (Original) The method of claim 1, wherein locally tracking protocol progress 
information within each member of the group includes locally tracking within the selected 
member protocol progress information associated with at least one other member in the group. 
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Claims Appendix : Claims on Appeal 09/732,189 

12. (Original) The method of claim 1, wherein locally tracking protocol progress 
information within each member of the group includes locally tracking within the selected 
member protocol progress information associated with all other members in the group. 

13. (Original) The method of claim 1, wherein locally tracking protocol progress 
information within each member of the group includes locally tracking within each member 
protocol progress information associated with each other member in the group. 

14. (Original) An apparatus, comprising: 

(a) a memory; and 

(b) a program resident in the memory, the program configured to determine a 
status of a peer protocol initiated on a plurality of members of a group in a clustered 
computer system by locally tracking protocol progress information within at least one 
member of the group, and providing the protocol progress information locally tracked by 
a member of the group in response to a query directed to such member. 

15. (Original) The apparatus of claim 14, wherein the program is configured to locally 
track protocol progress information by tracking, within a first member of the group, 
acknowledgment (ACK) messages directed to the first member by each other member of the 
group. 

16. (Original) The apparatus of claim 14, wherein the program is configured to locally 
track protocol progress information by tracking, within a first member of the group, a current 
acknowledgment (ACK) round for the first member, and tracking, within the first member, a last 
ACK round received parameter associated with each other member of the group, wherein the 
current ACK round is associated with a current peer protocol being processed by the first 
member, and wherein the last ACK round received parameter for each other member identifies a 
peer protocol associated with a last received ACK message from such other member. 
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Claims Appendix : Claims on Appeal 09/732, 189 

17. (Original) The apparatus of claim 14, wherein the program is further configured to 
wait on a resource required by a protocol being processed on the selected member, and monitor 
for receipt of the query by the selected member while waiting on the resource. 

18. (Original) The apparatus of claim 17, wherein the protocol is a peer protocol, and 
wherein the program is configured to wait on the resource by waiting for receipt of an 
acknowledgment (ACK) message directed to the selected member. 

19. (Original) The apparatus of claim 17, wherein the protocol is a local protocol, and 
wherein the program is configured to wait on the resource by waiting on a local resource 
requested by the selected member. 

20. (Original) The apparatus of claim 17, wherein the program is configured to locally 
track protocol progress information by locally tracking within a first member protocol progress 
information associated with at least one other member in the group. 

21. (Original) The apparatus of claim 17, wherein the program is configured to locally 
track protocol progress information by locally tracking within each member protocol progress 
information associated with each other member in the group, 

22. (Original) A clustered computer system, comprising: 

(a) a plurality of nodes coupled to one another over a network; 

(b) a plurality of member jobs defining a group and configured to be executed by 
at least one of the plurality of nodes; and 

(c) a program configured to be executed by at least one of the plurality of nodes 
to determine a status of a peer protocol initiated on the plurality of members by locally 
tracking protocol progress information within at least one member of the group, and 
providing the protocol progress information locally tracked by a member of the group in 
response to a query directed to such member. 
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Claims Appendix : Claims on Appeal 09/732,189 

23. (Original) A program product, comprising: 

(a) a program configured to determine a status of a peer protocol initiated on a 
plurality of members of a group in a clustered computer system by locally tracking 
protocol progress information within at least one member of the group, and providing the 
protocol progress information locally tracked by a member of the group in response to a 
query directed to such member; and 

(b) a signal bearing medium bearing the program. 

24. (Original) The program product of claim 23, wherein the signal bearing medium 
includes at least one of a recordable medium and a transmission medium. 

25. (Original) An apparatus, comprising: 

(a) a memory; and 

(b) a program, resident in the memory, the program configured to monitor for 
receipt of a query message by a member of a group in a clustered computer system while 
a current protocol for the member is waiting on a resource, the program further 
configured to output protocol status information in response to receipt of the query 
message. 

26. (Original) The apparatus of claim 25, wherein the resource is selected from the 
group consisting of a local resource and an acknowledgment (ACK) message. 



-A-5- 



PAGE 23/23 * RCVD AT 12/22/2004 3:04:04 PM [Eastern Standard Time] * SVR:USPTO-EFXRF-1/3 * DNI8: 8729308 * CSID:513 241 6234 " DURATION <mm-ss):08-46_ P . 23 



